AmigActive 24

home *** CD-ROM | disk | FTP | other *** search

/ AmigActive 24 / AACD 24.iso / AACD / Information / WebSites / Eyetech / amigaone / faq.php < prev next >

Wrap

Text File | 2001-08-06 | 63KB | 1,380 lines

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html> <head> <title>AmigaOne : Frequently Asked Questions</title> </head> <style type="text/css">     </style><body bgcolor=white text=black topmargin=0 leftmargin=0 link=red vlink=red alink=#CE0000> <basefont size=1 face=Verdana,Arial,Helvetica> <table cellspacing=0 cellpadding=10 border=0 width=100%> <tr bgcolor=red> <td width=10%></td> <td width=*></td> </tr> <tr> <td height=75 colspan=2 bgcolor=red> <img width=410 height=47 src="logos/amigaonelogo.gif"> </td> </tr> <tr> <td height=2 colspan=2 bgcolor=black></td> </tr> <tr> <td align=center valign=top> <center> <a href="/"><img border=0 width=100 height=22 src="logos/eyetechlogo.gif"></a> <a href="index.php">Latest News</a> <a href="information.php">Information</a> <a href="pictures.php">Pictures</a> <a href="faq.php">FAQ</a> <a href="timeframe.php">Timeline</a> <a href="betatesting.php">Beta Testing</a> <a href="mailinglist.php">Mailing List</a> <a href="dealers.php">Dealers</a> <img width=70 height=70 src="logos/ngboing1.jpg"> <a href="/">Back to www.eyetech.co.uk</a> </center> </td> <td align=left valign=top> <img width="150" height="75" src="logos/faq.gif"> Which is faster - AmigaOne 1200 or AmigaOne 4000? Both will be the same speed given the same CPU. What about the reliability of the expansion connector on the A4000 compared to the A1200? Remember that the AmigaOne is a complete single board (+ PCI/AGP slots) in its own right. The A1200 edge connector and A4000 CPU connector are only used for accessing the custom chips (at relatively low speeds) by applications that 'hit the hardware' directly. Eventually with a fully retargetable OS & applications the original A1200/A4000 will be redundant. Will the AmigaOne 1200 fit in XXX tower? The AmigaOne will fit in any tower which is compatible with the Z4 busboard, as it is designed around this form factor. Towers which it will fit are the Eyetech Z4 Tower and Elbox Tower / Power Tower. It will not fit an Eyetech Mk.1-Mk.5 Tower. If you are aware of any other towers which fit the Z4 busboard form factor, please let us know. I've got an A3000 - you've forgotten about me! No we haven't, as stated in a previous Eyetech press release, if you are interested in potentially purchasing an AmigaOne for another type of Amiga system it would be enormously helpful if you could <a href="mailto:sales@eyetech.co.uk?Subject=AmigaOne for ">email</a> our sales address indicating in the subject line the type of system you would like to use the AmigaOne with. Your subject line should read "AmigaOne for xxxxx" where "xxxxx" is: - "A4000 desktop tower conversion using (manufacturers name) tower" or - "A4000T tower Amiga International design" or - "A3000 desktop system by Commodore" or - "A3000 tower system by Commodore" Will the AmigaOne 1200 work with XXX expansion? PowerFlyer / Elbox IDE Flyer These will be redundant, as there is a 4-device UDMA IDE controller on the AmigaOne itself. Prelude 1200 / Clockport Serial & Parallel / Catweasel These will be supported, as the AmigaOne will be operating in AmigaDOS compatible mode. However, the optional PCI soundcard + drivers will give much better performance, as will similar solutions for serial, parallel & floppy drive expansion. Can you estimate how much it will it cost? As far as price is concerned we obviously have our own estimates, but these are at this stage within fairly broad bands to allow for variations in the market price of chips, exchange rates etc at the time we place the main bulk orders. If we were to fix our prices now then we would have to opt for prices that fully covered the risk of worst case purchasing and exchange rates - which would not be in the interest of end users. The only estimation which we are able to release at this time is that the AmigaOne 1200 / 4000 will be significantly cheaper than the current top of the range Amiga PPC accelerators, while offering a major increase in performance and functionality. What is the fastest G3/G4 processor that can be attached? The processor will be mounted on a support card - we see no speed restrictions on the use of currently available processors within the limitations of the pinouts. How will drivers be handled? Obviously, after installing new hardware, you will have to install the appropriate driver. However most drivers will fit in the FlashROM, which can be write-protected. So after that, the AmigaOne will perform a fast and reliable reboot, with the new hardware being instantly available to the OS. Will the AmigaOne be able to run Linux? Yes, if someone recompiles the kernal etc to suit. Will you be supplying XXX drivers with the AmigaOne? The initial release operating system shipped with the AmigaOne will have drivers for graphics and IDE UDMA, with USB, firewire, ethernet and soundcard drivers following shortly afterwards. A PCI resource library with published API entry points will be supplied for individuals / organisations wishing to port drivers for other hardware. What speed of SDRAM DIMM's does the AmigaOne need? PC100 or better. Will there be an updateable flashrom on the AmigaOne? Yes. What sort of connector is used for the G3/G4 processor? Can I buy a Mac-style CPU upgrade? A universal 'Slot 1' type CPU connector will be provided with adaptors being available for most popular pinouts / form factors of Mac-type G3/G4 CPUs. How will the keyboard and mouse connect to the AmigaOne? The existing Amiga keyboard & mouse/joystick will continue to be able to be used, although drivers will be provided for their USB equivalents in due course. On the AmigaOne 4000, will I have any Zorro slots remaining? Currently, it does not look like it will be possible to add a Zorro slot from an engineering point of view. But we are still looking to see if there is a possible way around this. However most of the functionality of Zorro cards will be available, better and cheaper, using the PCI route. Will the "8MB memory window" affect the AmigaOne? No - it could access this area, but does not make use of the A1200/A4000 Zorro II address space. Is it still possible to access the PCMCIA port with the AmigaOne 1200? Yes. Will it be possible to overclock the G3/G4 CPU? Not within the warranty arrangements, and we would not advise it anyway. Will there be a jumper to prevent flashrom upgrades, to avoid virus problems? It will be possible to write protect the flashrom. Where can I buy the AmigaOne? What bundles will be available? The AmigaOne -1200/4000 came out of work that we were already undertaking on the Predator-Plus, but substantially revised to make it fully compliant with the Zico specification from Amiga. Whilst the Predator-Plus was our own (Eyetech's) product to sell directly and via the distributors which we selected, the AmigaOne 1200/4000 is to be 'open availability' - that is available at the same price and under the same conditions to any bona fide Amiga dealer worldwide. There will be no territorial 'exclusives' either in the UK or elsewhere. How does this work in practice? Well the development and manufacturing sides of the AmigaOne 1200/4000 are being undertaken by a consortium of companies, including Eyetech's industrial systems division, Escena and others. There is open accounting between consortium members and a contractual undertaking as to how the costs, risks and margins on the manufacture of the boards will be shared, and on the cost price to dealers. The prime concern of the development/manufacturing consortium will be to make sure as many boards as possible are sold in order to recover development costs and generate economies of scale. All dealers, whether existing competitors, partners or otherwise, of any of the manufacturing consortium, will be able to buy the AmigaOne 1200/4000 at exactly the same price as Eyetech's retail division does. This will ensure wide availability and price competition amongst the dealers and the best deal for end users. The only constraint on dealers is that each dealer will need to buy boards in minimum quantities of units, cash with order, and have at least one physical, named person able to support end users who buy the product. Dealer margins at recommended end user prices are sufficient for the dealers to be able to provide this level of support. The manufacturing consortium will sell bare boards to dealers, for them to add their own SDRAM, I/O & graphics cards, cases, storage etc. We will also make the specification for the CPU slot open , so that other companies can build CPU modules, in addition to the ones the consortium builds. The pinout has been agreed (last October) with bPlan so CPU modules manufactured by them should work in the AmigaOne 1200/4000 and vice versa. We will also be making the adapter boards which carry, as one example, the 'mac-type' ZIF CPU/cache modules available to dealers for them to fit their own CPU's. In fact our philosophy is to build adapter boards which can be used with any G3/G4 modules which are readily available either new or second user (eg from Mac owners upgrading). Individual dealers will have the option of what specification and how many CPU modules to buy from us and from the other CPU module suppliers. We expect that most dealers will sell both the AmigaOne boards/CPU's and fully towered, ready to roll systems. They will be able to buy the Eyetech EZTower-Z4 (or equivalent towers from other manufacturers) if they wish to sell a system with an AmigaOne and A1200 integrated in the same case (necessary to run OS4.0) or a system with an AmigaOne 1200 board in an ATX case (without an A1200) for retargetable applications from OS4.2 on. As far as Eyetech's retail operations are concerned we will certainly offering both 'board-only' upgrades and custom built ready-to-run systems. As well as the choice of CPU and memory you will also be able to add (specified) PCI/AGP graphics, networking, modem (ISDN), firewire, SCSI and sound cards either buying them direct from your dealer or elsewhere. Some of these cards will have drivers provided with OS4.x and some will be provided by third parties. In addition the on-board 2xUSB and 4xUDMA-ATA channels will have drivers provided as part of OS4.x. As far as preorders are concerned, our retail operations are certainly taking 'no-obligation, no charge' preorders to help them decide on the level of initial demand for the AmigaOne 1200, and I imagine other dealers are doing the same. However we have also stated that final pricing will not be released (by the manufacturing consortium) until the board goes into final production so that we can set the best possible price based on optimising component pricing, exchange rates etc. Will you be supporting MorphOS? Our main (and only current) objective is to produce the first new Amiga in 10 years for the Amiga community, running the Amiga operating system specified/developed by Amiga Inc. When will an ATX board be available? The AmigaOne 1200 is an ATX board as well. See picture of it in a standard ATX tower. <hr width=50%> Most new minor information concerning the AmigaOne has been released on the mailing list rather than on this FAQ. Hence what follows is excerpts containing factual information taken from the mailing list. <pre> > This is the same problem with the Zorro slots for the AmigaOne 4000. > A large part of the present Amiga park is equipped with some boards > which don't have their equivalent in PCI. > > [snip] > > The Amiga market is so small that we cannot allow ourselves to lose > any potential buyers, and these people cannot lose all the work they > have been doing for many years. Ultimately the AmigaOne is a transitionary product designed to run the Amiga DE and its applications in stand alone mode, and either fully retargetable Amiga applications - or those which rely on the AA chipset - in the meantime. It is not designed to run Classic Amiga applications that rely on specific Zorro hardware. If this is your requirement then your only (guaranteed) option is to keep running your existing hardware (possibly networked to the A1) at present, and ultimately replace it with functionally equivalent (ie better) PCI hardware and associated software running under the Amiga DE. > In fact, as an Amiga dealer we know that about 50% > of our customers have a SCSI configuration. > We do not want to lose this market and we are sure you do not want too. > It's not the time to do again the same mistakes done in the past ! > Many A3000 users didn't buy the A4000 one when it was released > just because of the SCSI and the flicker-fixer. > You can't tell a third party will be able to write the driver. > You must reassure the Amiga cummunity and tell them > that a SCSI solution will be ready when the AmigaOne will be launched. The AmigaOne 1200/4000 have been developed to the Zico spec laid down by Amiga Inc. This does not include SCSI or Zorro. However we fully expect SCSI drivers to be written/ported by third parties for one or more specific cards shortly after the board starts shipping. As far as Zorro compatibility is concerned the layout of the A1 main board is extremely critical because of the high speed of the bus etc. This causes a real problem in trying to route the 200 signal lines from the A4000's CPU slot to the Westbridge interface VLGA chip through the A4000's Zorro riser and potential Toaster compatible Zorro3/video slot (which uses a through hole connector and therefore uses space on all pcb layers). We're still looking to see if this can be solved reliably, and thats one of the reasons that the (simpler) AmigaOne 1200 is coming out first. If it can be done however it will add significantly to the cost of the AmigaOne-4000 because of extra PCB real estate and additional production costs. > Do you plan to include in the flashrom some VESA drivers so that we can see > the Early Startup Menu or the "BIOS setup" of the A1 on a SVGA screen ? yes this is the intention - but it will be implemented by third parties, so exactly how its implemented will be down to them. > I understand that the AmigaOne motherboard is going to use SDRAM PC100. > > How many slots will it have and what is going to be the maximum amount of > RAM that can it address? 2 x SDRAM slots 1GB of SDRAM address space has been allocated > So I was thinking that it may be possible to mount the AmigaOne in an > external case to the classic Amiga and then connect the CPU slot on the > classic Amiga to the AmigaOne's connector via a short cable? Or would > signal timing and synchronization issues prevent this from being a > workable solution? This is the whole issue. The whole board layout has to be optimised to work at these speeds, including trace length equalisation etc etc. Cables of any sort are certainly a no-no. Although the A4000 & A1200 versions share much of the same internal logic they are completely different board layouts, needing separate testing, production setup etc. The additional development costs per new board layout through to being 'production-ready' approach USD 6 digits (without our apportioned overheads) so we have to be very sure of future sales potential before embarking on an AmigaOne 3000 design. And that still doesn't solve the Zorro issue, as previously discussed. Perhaps a better approach might be to buy a complete A1200/AmigaOne/Z4Tower and network it to your A3000. That would almost certainly come in significantly cheaper than an AmigaOne 3000. > I hope the flashrom implementation will be "secured" in some way, such as > write access being dependant on something physical, like a shorted serial > port lead (to stop virii writing themselves to the "bios") This has already been covered in this list. Yes the Flashrom will be write-protectable. > PS: with the AmigaOne / hardware interface for backwards compatibility, > would it be possible to speed up the emulation layer by copying the roms for > instance, to file on the AmiOne filesystem Its much faster to copy the ROMs to RAM, than to copy an HD image of the ROMs to RAM. > I was obviously not the only one who thought only a single DIMM was > required. You only need 1 SDRAM DIMM, and if you use 2 they can be of different sizes. > When I get my mits on the new Amiga One-1200 I'll be using it in a > Eyetech-Z4 tower with an original A1200 to start with. > > How do I power them both from the same internal PSU? Sorry if this > has an obvious answer, but I'm a thicky... The EZ-Tower Z4 has an ATX power supply in, and the AmigaOne has an ATX PSU connector on it. You will be able to connect these two - and voila - power :-) Power to the A1200 motherboard can pass through the A1200 expansion connector - as the amount required by it will be minimal. If extra power is required (perhaps because of a lot of classic peripherals on the A1200 m/b), then power can be applied to the A1200 floppy drive power connector. > All well and good for the dealers/system builders but what about us > normal non-dealer type people?? You buy from dealers (including, if you wish, Eyetech's retail division) just as you do with any other piece of Amiga or PC computer hardware. > I've got a suggestion though. Given that there is a lot of interest in > the Linux world for non-Apple PPC systems, would it be worth while to also > consider putting together AmigaONE systems that would include a Linux > distribution (Mandrake is my favorite) along with the Linux AmigaDE SDK? > That would give you guys a very open market, particularly once the > application builder is finished (next DESDK release?). First things first. Our main (and only current) objective is to produce the first new Amiga in 10 years for the amiga community, running the Amiga operating system specified/developed by Amiga inc. Whilst Amiga Inc are getting all the details of OS4/5 up on their own website I thought it might be useful to give my own views as to where we are, where we are going and why the St Louis announcement was so pivotal to the future of the Amiga. Its quite long I'm afraid, but hopefully a useful basis for further discussion. If the general consensus is that it helps clarify the issues involved I'll also stick it in the AmigaOne section of our web site. If I've got some details wrong I'm sure Fleecy will comment ;-) Over the last few months we have been working closely with Amiga Inc to ensure that the AmigaOne is worthy of being the next generation Amiga - and that of course means that it must have a robust, expandable, secure, efficient real time operating system. But that was meant to be the Amiga DE wasn't it? Well yes and no. The Amiga DE is a quite basic real-time operating system designed primarily for single tasking - and certainly single user - operations on embedded systems such as set top boxes, PDA's, cell phones etc. And since these devices have both low power cpu's and very limited user interfaces the DE needs to be free of much of the clutter that we normally take for granted in a desktop operating system. On the other hand a home server - the central box that coordinates all the Amiga DE devices and runs 'proper' desktop applications - needs many more facilities, such as task-level memory protection and OS-level virtual memory, that are not practical to implement within the DE without completely compromising its portability and speed. So what we have now ended up with is the best of both worlds. Desktop Amiga users will have a desktop/server OS, natively coded for the PPC, with added memory protection, virtual memory and a much improved file system, whilst still retaining the efficiency, real time responsiveness, elegance and familiarity of the Classic Amiga OS. The DE will follow its own development path but be totally integrated within OS4+ Developing the new OS is to be a 4-stage process: - OS4.0 will be an updated version of OS3.9 with special facilities added to allow existing classic Amiga applications to run on the AmigaOne, accessing the classic Amiga hardware via the hardware bridge on the AmigaOne 1200/4000. Much of the operating system will still be in 680x0 code with in line instruction conversion to PPC code. - OS4.2 will add additional features and the recoding of much of the OS in native PPC code. However the major milestone in this release will be the complete retargeting of all operating system I/O away from Amiga specific hardware/chipsets. This means that retargetable 'Classic' applications can be run on the AmigaOne (or any Zico-compliant PPC board) without any 'classic' Amiga hardware present. At this stage the Amiga DE will also be ported to the Amiga OS so that the AmigaOne can be used as a development/porting platform for Amiga DE content (as a more familiar alternative to the currently available Windows/Linux development environments). Drivers will obviously be provided for those resources which are retargeted to the AmigaOne motherboard (USB, sound, graphics, UDMA etc). - OS4.5 will be an entirely PPC-native, entirely hardware independant version of the operating system, with full driver support for all Zico resources (FireWire, Matrox NG graphics cards, SCSI etc) - OS5 is a full 64-bit fully distributed AMP operating system which will implement virtual memory, memory protection and the Amiga DE in a fully-spec'd, modular home-server/desktop OS. OS4.x will only run on PPC boards conforming to the Zico specifications which excludes BlizzardPPC & CyberStormPPC accelerators - even when coupled with a Predator-SE PCI bus. We (and Amiga Inc) are pressing DCE, the current manufacturers of these boards, to come up with a 'Zico compliance kit' to preserve the investment of existing BPPC/CSPPC users and allow them to run OS4.x. Of course this means that - from OS 4.2 on - you will only need a existing 'Classic' Amiga for those few applications that are genuinely not retargetable (ie those that still insist on 'hitting' the classic hardware). All of the existing application software developers we have spoken to are more than willing to port their applications to a fully hardware independent PPC AmigaOne. This also means that by the time we would have scheduled the design and production of the AmigaOne 3000 it would probably be an irrelevant piece of hardware as far as most users are concerned. We're not closing that door just yet, but, because of this hardware independance from OS4.2 onwards we believe that existing Ax000 users will be able to run their applications on stand-alone AmigaOne PPC hardware much sooner than we had originally anticipated. And as far as that most famous of all big-box Amiga accessories is concerned - the Video Toaster - we are going straight round to NewTek ask them to port drivers for their existing PCI-based Toaster to OS4.x as soon as production AmigaOnes are released! Finally, one of the most significant parts of the announcement is that Amiga Inc have decided - quite properly in my view - to take their ownership of the Amiga OS seriously. They are taking development control, standards definition and quality assurance for the Amiga OS back in house for the first time since 1984. This is the first step in ensuring that we are no longer blighted with compatibility issues between different software modules, or 'kernel wars' between third party developers. Provided everyone is sufficiently unbiassed to see the move in this light there is no reason why Amiga shouldn't choose the best elements from Haage & Partner's WarpOS, Ralph Schmidts's MorphOS, the work from the AROS project team and the existing Classic OS in developing OS4 & 5. The important thing is that we now have - in the shape of Fleecy Moss - a combined helmsman, navigator and Captain for the Amiga OS. And I for one am fully committing our AmigaOne hardware to Amiga's new OS strategy - for the sake of forward compatibility and reliability - and without the diversion of seeing if we can get Linux, MorphOS or anything else running on the AmigaOne board. > I have been looking at the pics on the Eyetech site and have noticed the > following pieces missing from the board...... > > 1. Keyboard socket > 2. Floppy interface > 3. Serial port > 4. Paralell Port All via USB as per the Zico specs. USB adapters for these things are readily available & cheap if you dont want to use a direct USB accessory. > I think that the addition of an A1200 motherboard may cure these problems > (apart from the keyboard probably), but what if you are going to use the > A-One board as standalone? You can of course continue to use the A1200 I/O up to OS5 - the retargetability includes being able to retarget back to the original A1200 I/O. > The problem is the non-retargetable programs. Having used a Draco, I > know that this is a major practical problem. There are still many > essential programs which run (legally) on AGA, as that is the official > requirement for a legal Amiga program. Most of the companies concerned > are out of the Amiga market, and generally have lost the source code. > > Scala is an obvious example. ProDraw, Brilliance, ImageMaster, DPaint, > etc are all still useful. > > And won't people want to play classic games? Yes - and they have 2 choices - keep the original Amiga connected to the AmigaOne, or remove it and us it on its own for those odd, (sad?) retro moments. What the AmigaOne 1200/4000 gives is a modern computer and operating system and 18-24 months breathing space of full compatibility (before OS5) > The point is that some subset of UAE needs to be built into the RTG > system, to emulate AGA on the new graphics cards. The alternative, of > course, is the hardware emulation that is supposed to be in the BoXeR - > but that may never happen. My understanding is that this dioes not form part of AI's plans and I wouldn't want to ask them to do anything else that pushed back thier timescales. I agree that a UAE-type solution might be the best option for compatibility with old low resource - demanding games for people without 'classic amiga' hardware attached, but I would swee this as just another application running on top of OS4/5 - like Amiga Forever does on Windows. I'm sure someone will want to port it, and at least we will have decent hardware resources and a fast, documented, realtime OS to provide the support functions. >> Of course this means that - from OS 4.2 on - you will only need a >> existing 'Classic' Amiga for those few applications that are genuinely >> not retargetable (ie those that still insist on 'hitting' the classic >> hardware). > > Will the later versions still support the A1200 motherboard for this? Up to OS5 the original Amiga hardware, if attached, will form part of the retargetable resources targets. > If I read this right, this means that PCI cards will not be working in > OS4.0, so you won't be able to retarget graphics and sound to the > newer hardware? No, that is incorrect. OS4.0 will support current PCI cards which are available through existing API's > How about we have a "Boing" key & an "Amiga" key instead, > for any new keyboard standards, with suitable stickers supplied..... If we can standardize on a particular model of PC k/b we can easily and cheaply have special keycaps engraved/printed. > What is the entry level CPU for the amigaOne It will be down to the individual dealer as to which cpu models/speeds he stocks but wit the Mac zif 233 G3 0.5MB backside cache being available for about USD30 that realistically will be the entry level > Will this EZKey-XS adapter be (optionally) bundled with the AmigaOne? This is a product that is and will continue to be made available to other dealers. Bundling is not appropriate as many A1 purchasers will already have suitable towers and keyboard adapters from us, elbox and/or our respective dealers. > And now for the old question: > > In a previous message you mentioned an "xMON" switcher for SD/FF usage. > Will this xMON switcher be offered as an option at purchase time? Bundling/availability - same as above. The xMON takes video output from any internal scan doubler (optionally with flicker fixer) and from the 15pin SVGA connector of the graphics card in response to a control signal. Ideally the control signal should be issued by the RTG driver when it switches the current display between AGA & graphics card. (The CV64-3D card provides such a switching signal for example). Alternatively it can be switched via hardware on the k/b adapter in response to a particular key combination (Amiga-Amiga-up arrow in the case of the EZKey-XS - see the docs on our web site www.eyetech.co.uk for more info) - or even by a front panel switch. Since this feature will only be needed when an actual A1200 is attached it does not really make sense to build in the extra hardware latches etc needed onto the A1 mobo as that then increases costs for everyone whether they need it or not. However it is perfectly feasible that the RTG driver could trigger a pin on the A1200 mobo that is unlikely to be used in its A1-1200 configuration - eg on the external floppy connector - to provide automatic switching. > And which kinds of ScanDoublers/FlickerFixers does it support? All actually, but internal ones make the cabling easier. the 'x' in xMON/y refers to the graphics card connection and the y refers to the AGA-side connection x=S -> SVGA (15p) gfx card x=B -> B/CvPPC gfx card x=A -> CV64-3D (autoswitching) y=F -> internal DCE-style SD &/or FF y=V-> VGA (15p) SD/FF connector (external SD/FF) y=A-> Amiga 23p RGB connector > I am still interested in anybody's comments on my previous post, > especially about what will happen to classic hardware and software > compatibility in OS 4.2+. Even though 4.2 allows "all applications > to be able to operate without the need for physically attached older > Amiga hardware", that doesn't imply to me that we'd be _forced_ to > give up anything. This is not quite correct. By 4.2 all OS functions will be hardware independant (ie the can use hardware resources provided either by an attached classic Amiga or the A1 board) but programs that have been written to hit the classic hardware direct - eg Scala MM400 - will still require an A1200 to be present to provide those hardware resources. 'OS legal' classic programs shoud run fine without an attached A1200. > Under OS5, I see Amiga implementing the more > cutting-edge ideas they originally talked about when bringing AmigaDE > to the desktop, and we might infer that classic compatibility would > stop here... Its meant to run OS4 (and therefore retargetable Classic apps) in a 'sandbox' (or should that be sandpit???) > have you decided to definitely build the AmigaOne-4000 Our first priority is to get the A1-1200 in production, and we are about 1 week behind target with that (but still within the delivery timeframes of OS4.0 - so no end user slippage). Once that is done we will cost out the design/production of the A1-4000, and estimate the time to ship. However this is likely to be in the same timeframe as the release of hardware independant OS4.2 (which was never on the cards when we first announced the A1-1200/4000). That means all hardware retargetable applications will (should!) run without an attached Classic Amiga. That in turn means that we would be only building the A1-4000 for those that had applications that were impossible to retarget - ie an even smaller target market. For these applications, many will be superceded with ppc/A1- native applications (eg video editing etc using firewire) whilst others will not really gain anything from moving them to an A1-4000 platform (there is no benefit as far as I can see for running a video toaster at 600fps!). For these applications perhaps the most sensible solution is to keep the A4k as it is with a high-speed network link to a standalone A1 where all the processor intensive work can be carried out. If this is realistic then the target market for the A1-4000 shrinks again. Below a certain point the level of sales means that the A1-4000 becomes economically unviable to develop and manufacture, and that is the caclulation we need to do after we have re-assessed the development/production costs. If the numbers stack up we'll do it; if they don't we won't. > "While I can accept that my Mk.4 Eyetech EZTower is going > to have to be replaced if I want to enjoy the AmigaOne 1200 in > a few months time, I find myself rather frustrated by the > alternatives. If yo want to continue to use the Mk4 EZtower you can mount the A1-1200 in the AT/ATX side of the tower and network it internally to your existing A1200. Obviously the A1-1200 doesnt have direct access to the AA chipset in this configuration so you'll have to wait for OS4.2. Then run retargetable applications on the A1 and non retargetable apps on the original A1200, sharing storage, keyboard, screen etc. > Show me an official statement (i.e. a posting, web page, IRC log) > where an Amiga, H&P or Eyetech employee states that AOS 4.0 won't run > existing WarpOS software. You won't find any. > > Of course AOS 4.0 will be able to run WarpOS software, anything else > would be quite stupid. OK time to kill some wasted bandwidth here Heres an official statement. "OS4.0 will run existing WarpOS apps" > As you canan probably tell from the pictures of the board, the AmigaOne > uses ATX power. However, atm my A1200 is powered by an AT power supply in > my PowerTower, through a Mediator. > > Will the AmigaOne's power supply be used to power the A1200 mobo in a > similar fashion to the Mediator and other busboards? My guess is yes, but > just for comfirmation... :) Yes (just like all the other PCI cards!) >> So why are Amiga giving a copy of 4.0 and 4.2 away for free if you >> buy the SDK1.1? You will just have two copies of 4.0! Surely? > > Presumably because you have to pay /extra/ for OS4.0 when you buy an A1; say > $500 for the hardware plus $100 for the software. (Somebody already made > the point that two different companies are involved, Eyetech and Amiga.) > The offer then gives you a saving of $100, either on the OS or on the > machine, depending which way you look at it. The A1-1200 will be sold via dealers (including our retail division) who will all purchase at the same price. Dealers will buy A1 boards from the manufacturing division. They can then buy CPU modules and A1200 tower cases from us or elsewhere They will buy memory, HD's, CD/DVD ROMs etc etc from their regular local suppliers They will buy OS 4.x from Amiga Inc or their nominated distributor. This will be needed unless the A1 is bought as a hi-tech paperweight. The dealer will then have the option of selling individual boards/cpu modules/OS4.x, fully configured A1200 tower upgrade kits, fully built systems, or, from OS4.2 onwards, fully configured systems in a standard ATX case without an A1200. We can not add any value - only cost and margin - by selling dealers things that we do not produce, and this includes OS4.x. Thats why dealers will add OS4.x into the bundle themselves. If the voucher is (via dealers) applied to the A1 then we rebate the dealers. If to OS4.x then AmigaInc's OS4.x distributor rebates the dealers. </pre> <hr width=50%> AmigaDE / AmigaOne audio - report from Simon Goodwin On 28-Mar-01, Don Cox wrote: > Hello Simon > > I'm forwarding this from the AmiOpen list. I would think NDAs prevent > most of the questions from being answered. Indeed, but they are sensible questions about issues which do concern us, and they can be answered in general, as the chip at the core of our system is public knowledge, and outline specifications for it are available. So it's time to open the kimono, a bit... :-) Before I start, I should say that this text and the accompanying diagram is a description of work in progress. It's likely that there will be several versions of the product with varying features. This is not an offer for sale, and we reserve the rights to add or remove features from the released product or to change aspects of the implementation. But this will give you a good idea of what we plan. > *** Forwarded message, originally written by unlyrn on 27-Mar-01 *** > > A while ago I asked if we could get a bit more info on the audio > situation, I don't recall ever getting a reply, Gary? afaik, Simon Goodwin > (my apologies if that's wrong) is the audio guy there at AI, perhaps he > could answer a few questions... Firstly, how far along is the audio engine > in AmigaDE? I don't have access to the SDK, but I'm assuming audio output > is only in stereo? I'd really love to see multi-channel audio I/O running > in a hosted environment (eg an AmigaDE software sampler outputting on 8 > channels via a Windows ASIO card), but if this is not going to happen, I'd > like to know sooner rather than later... The streaming system in the AmigaDE supports any number of streams and any number of inputs and outputs. The minimum a hosted environment must support is stereo output, but the existing DSFX allows multiple applications to write to that simultaneously. Of course a pure Amiga system such as AmigaOne must do far better than that! The soundcards we specify support many simultaneous outputs - the exact number depends on the card and not all will necessarily be wired up - you can't get all the sockets on the bracket of a single PCI slot! - but the EMU10K1 DSP chip which is the core of the audio hardware we specify for ANY new system compliant with Amiga low-level audio drivers has the following outputs and inputs: DIGITAL outputs - four stereo channels FOUR stereo digital audio outputs configurable to AES/EBU (professional XLR digital audio), S/PDIF (phono domestic digital audio) or TOSlink (optical) standards. These can support AC3 Dolby Digital compressed surround sound, or be used in combination to provide uncompressed true 3D surround sound for more speakers with far more flexible configuration than Dolby or DTS can offer. DIGITAL inputs - two stereo channels You don't ask about this, but inputs are just as important to us. There are two digital inputs which support all the above standards and - most crucially - can operate at any standard sample rate, automatically synchronising to the internal rate of the Amiga. So you can feed audio directly from DATs, CDs, DVDs and MiniDisc hardware into our system and mix between them without sync or sample rate problems. Either of these inputs can also handle AC3 Dolby Digital 5:1 format, and route it without data loss to one of the ditial outputs. Analogue channels: stereo in and one, two or four out! In addition to these standard digital audio connections the design has provision for standard analogue to digital converters (ADCs) and digital to analogue converters (DACs), which you can plug into amplifiers or other analogue equipment. The standard for connecting analogue signals to a digital signal processor is I2S, which supports a stereo stream in one direction. We have dedicated connections for I2S input and output to the analogue world. We can also set one of the aforementioned digital outputs to work in I2S to drive a second stereo analogue amplifier. We also have a separate I2S input (with sample rate conversion) for a tuner card or other expansion card internal to the Amiga. There is another way to get extra outputs without changing the chip at the core of the Amiga audio-subsystem or the software interface to it. Sound cards used to be built with separate stereo ADCs and DACs, and Amiga supports this as it give the best quality. But the first pair of I2S input and output connections previously mentioned can be configured as an AC97 digital interface for an external codec - an all-in-one input and output chip. AC97 is the de facto standard for 16 bit in and output on a 'PC' (spit) and normally supports a stereo output and separate stereo and mono inputs. However we support the updated 2.1 version of the AC97 spec which allows up to eight DACs embedded in a single chip. Typically AC97 support on a PC motherboard is limited to stereo, but codec manufacturers are now making parts with two, three or four stereo DACs encapsulated. Thus the upper limit of an Amiga system - with a single DSP - is four stereo digital outputs, AND four stereo analogue outputs (via AC-97) - that's up to sixteen mono outputs all with different data and nine mono inputs (stereo and mono analogue, one I2S internal, and two TOSlink/S/PDIF/AES-EBU) all potentially at different sample rates. All these can be up to 20 bit resolution, depending on the ADC and DAC connected. It makes no difference to the programmer. The streaming software supports 8, 16 and (prefered for mixing and serious work) 32 bit samples. 192 dB should be enough headroom, we hope :-) So far I've only talked about the DSP which is on the new Amiga PCI bus. In theory you could have more than one of these, but you'd start to run short of bandwidth - there is meant to be some time left over for video, hard drives and other DMA, after all - the whole point is that this is designed as a complete co-operative system rather than a one dimensional PC benchmark engine. We're not planning to make PCI soundcards - Creative can do a good job of that (well, with help from E-Mu and Ensoniq they certainly can)- though it's possible that we'll get the EMU10K1 and associated interfaces on the motherboard of a future integrated Amiga. For the time being the slot approach means you can pick the number of and type of ports to match your budget. This is more flexible than the old Amiga approach of having pretty good facilities for all (very good, by 1985 standards, not so impressive now) and means we can develop to a sensible minimum standard without being boxed in (literally or metaphorically) later. We are investigating FireWire and mLan and a load of other systems for high-end audio workstations, for example, but they are not the focus of current work. The limits of contemporary cards stem not from the DSP or Amiga's software but what the manufacturer has put on the board. Thus you have a choice, from the bottom of the range SoundBlaster 512 or Live1024 - with stereo line in, four analogue outputs and a couple of digital outs on the back panel, and extra digital ins for DVD etc internally - to the SoundBlaster Live Platinum which adds much of the extra capability in a 5.25" drive bay (the Live Drive) with optical and SP/DIF ins and outs and analogue headphone and microphone ports all conveniently on the front of your computer, and out of the way of the noisy motherboard and PCI electronics that would otherwise limit fidelity. There are half a dozen EMU10K1-based boards available; Amiga is not committed to any one of them in particular - our API talks to the chip on your behalf and makes whatever ports are available visible to the Amiga system. While the EMU10K1 is the core of our current designs, it is not the end of the line for us or the experts at E-mu that designed it. It does most of what we want at the moment, and a lot more than any other PCI sound card solution, but we are fitting an API on top of it so we can upgrade the hardware and everything will still work - just better. Currently the sample rate limit is 53 KHz but this is just a hardware limitation and our system design does not tie us to this limit in future. We are aware that SuperCD and DVD offer higher rates, though there are unresolved standards and interface issues with those. Assuming we do OK with AmigaOne, we'd aim for rates of at least 96 KHz for audio workstations. AC97 is fixed at 48 KHz, with input conversion hardware so you can record to memory at DAB (32 KHz), CD (44.1 KHz), RealAudio (8KHz) or other rates like 11 and 22 KHz (ish) common on PCs and Macs. We can actually play samples by DMA at any rate up to the limit - much like Paula, but more so. Paula had four eight bit channels hard wired to left or right in stereo. We have 64 equivalent channels, except that we can mix or direct them proportionally to any outputs, and they can be 16 bit not just 8 bits wide, and at higher sample rates. Actually the EMU10K1 is much like an audio Copper - but one capable of implementing hundreds of parametric equalisers or mixer channels, rather than mixed-mode screens and palette stripes! I hope you can see that this is a system that deserves the name 'new Amiga', and are reassured that we know both what needs to be done and how to do it, now and in future. > Along the same lines, is any > extra latency introduced by hosting? In audio work, timing is everything, > if the hosting layer adds even an extra millisecond, or has 'jitters', > then its a big problem... anyone working on realtime audio software care > to comment? We are well aware of these issues and equally aware that existing computer 'system designers' are not. It is not possible to fix these faults retroactively, but we can and will fix them in our own system - by choosing components that deliver the Quality of Service you and we insist upon, and designing the system as a whole to deliver that potential. Hosting on a third-party OS is obviously limited by the implementation of that system. If it blocks interrupts or DMA or task-switching, the Amiga layer on top cannot magically cure the problem. It can only add latency, not remove it (the tardis is a long-term research project :-) though it can track it and endeavour to keep it consistent. You're quite right to assume that this limits performance on Windows, Unix or MacOS, none of which are realtime systems even by old Amiga 500 standards. For that matter, unapproved hardware or drivers can strangle 'modern' systems or PCI buses - this is not uncommon on non-Amiga systems and not something we can fix. 'Anyone working on realtime audio software' will want to use a system where Amiga controls the entire environment. AmigaOne is the first such system, closely coupled to the hardware so it does not have the limitations of hosts that are not designed for our Quality of Service expectations. > If nothing else, could someone at AI please forward this to Simon or > whoever else is the appropriate person, I'd really like to hear about the > audio layer of the DE, > Thanks, > David Shipman This is direct from Simon Goodwin, accept no substitute. :-) I have responded to this email because it's clear that you understand some of the key issues - we are well aware of those and others that you have not considered yet. Bear in mind that there are just five people in the core Amiga audio team, and they have lots to do. There are some other major Amiga audio developers and experts - such as Don Cox who forwarded this mail - advising the audio group. We're not hiding, but we are focusing on the real job rather than publishing wishlists or development diaries. We are also working closely with hardware partners, and programmers at Tao and Sseyo, but if you pester them about Amiga issues you're only going to piss them - and us - off. We shall release more information as we are certain of it, but some details will remain proprietary. So if you've not signed an NDA and got an SDK you will miss out. We are aware that the audio in the first SDK release was basic, but Amiga had nothing to do with that - it's just legacy from Tao's embedded systems. The forthcoming SDK 1.1 will add loads of audio and streaming media infrastructure, and Sseyo's extremely powerful generative audio synth (good enough for Brian Eno :-). Amiga will add layers on top of this, to manage streams and control signals and MIDI applications, and these will be available on all hosts. More important from your point of view, we shall add low-level device drivers specifically for the hardware we specify - initially based around the EMU10K1 though not bound solely to that in the way the old Paula drivers were - and those will deliver the realtime response and scalability you call for. E&OE! Further reading: Ambisonics: <a href="http://www.york.ac.uk/inst/mustech/3d_audio/ambis2.htm"> http://www.york.ac.uk/inst/mustech/3d_audio/ambis2.htm</a> <a href="http://www.stanford.edu/~mleese/Ambisonic/why.html"> http://www.stanford.edu/~mleese/Ambisonic/why.html</a> Explains how to support any number of speakers anywhere in 3D by mastering just four uncompressed streams, W, X, Y and Z. Some background on the EMU10K1 and its relatives: <a href="ftp://opensource.creative.com/pub/doc/m2049.pdf"> ftp://opensource.creative.com/pub/doc/m2049.pdf</a> <a href="ftp://opensource.creative.com/pub/doc/hog63.ps"> ftp://opensource.creative.com/pub/doc/hog63.ps</a> Note that Amiga has a lot more information than these (or the open source Linux drivers) contain but it is under strict NDA. AC97 specs (just for interest, not that we're limited to these) <a href="ftp://download.intel.com/ial/scalableplatforms/audio/ac97r21.pdf"> ftp://download.intel.com/ial/scalableplatforms/audio/ac97r21.pdf</a> Finally, please do NOT email us or our partners with requests for futher information or your advice on strategy or tactics. That will only cause delays. We will tell you more, and more concretely, as soon as we can, but need to concentrate on implementing what I have outlined, so you can play with that and extend it, rather than just dream about it. Cheers, Simon N Goodwin Contractor, Amiga Inc Team Lead, Audio Development <hr width=50%> AmigaOne SCSI standards - report posted by Amiga Inc Fleecy has also asked me to recommend a PCI SCSI card or chipset on which to standardise, and I'm fairly sure I know the right ones to pick. I've been a SCSI enthusiast since 1987, and written drivers for (very) dumb and smart controllers. I do understand the options and the issues, as I'll show. We should standardise on an 'NCR SCSI scripts' processor, for the following reasons. These are low-cost high-performance single-chip PCI bus-mastering SCSI controllers. They are widely available in SCSI 2 FAST and Ultra/SCSI-3 versions, originally from NCR then Symbios, now a brand of LSI logic, <a href="http://www.lsilogic.com"> http://www.lsilogic.com</a>. There is a good OEM support program there - another reason for chosing this rather than an Adaptec proprietary part, for example - and they encourage people to buy either boards with chips on (e.g. from lots of firms in China, Korea and Taiwan) OR the chips themselves for integration (as on Commodore's A4000T) so programming and electronic specs are both good and easy to get. Hence they are widely supported with free and compatible drivers, and as close to a commodity as controller chips get. You can buy PCI cards in this architecture from ASUS, Diamond Multimedia, DTC, Intraserver, Lomas Data, SW Technology, Topsys and Tyan, among others. Each offer versions that match several variants of the SCSI standard - unsurprisingly, as the software drivers and PCI connector stay almost the same, and only the integrated controller/interface chip and SCSI sockets need to change (basically). There are lots of chips in the 'SCSI scripts' family and they all have a similar programming interface, which I'm very familiar and happy with as both a user and a programmer. Chips in this family include the 53C710 used in the Warp Engine, CSA Magnum and A4091 (Zorro 3 cards and accelerators - I've written drivers down to the metal for these, in Amiga Qdos) which are SCSI 2 FAST. These were the fastest, lowest-overhead SCSI 2 controllers for Amigas, and in my experience very tolerant of cable and termination mistakes that clobber rivals. This feature is trademarked as 'TolerANT' and involves the controller monitoring the bounce on the I/O lines and tuning the line drivers accordingly. It works. :-) The Cyberstorm 3 and Cyberstorm PPC were based on a Symbios clone of the NCR53C770 Ultra SCSI script processor. Phase 5 abandoned the Elonex FAS216 they had inherited from the Fastlane Z3 cards and used in Mark 1 and 2 Cyberstorms, and so the Mark 3 was faster and more reliable, with lower CPU overhead than earlier models, even on 'narrow' SCSI drives. The main snag of the Mark 3 SCSI was that it only shipped with wide (68 pin) connections and required expensive connectors and cables to work with cheap and common SCSI 2 gear. It's important that we should offer a choice of SCSI 2 FAST and 'Ultra Wide SCSI 3' (pick your labels :-) controllers so people can use their existing equipment (scanners, DATs, ZIPs as well as intelligent fixed drives) with low cost, and those who have or want later 'wide' gear can use it, without us having to write new drivers. The most basic PCI version of this is the 53C810, which I use (in the SymBios remix) in my Devbox. The chip has the same advantages but even higher integration as it drops onto PCI rather than the CPU bus or - via glue - to Zorro 3. However SCSI 2 FAST is a minimum, these days; raw IDE can outrun it, though not if you have several drives active at a time. There are ultra wide and differential versions of the PCI chips, too. These are some of them - there are probably others: <ul> <li> 53C810A: Fast SCSI-2 (10 Mb/s) <li> 53C815: Fast SCSI-2 <li> 53C825: Fast Wide SCSI-2 (20 Mb/s) <li> 53C860: Fast-20 SCSI <li> 53C875: Fast-20 Wide SCSI (40 Mb/s) <li> 53C895: Ultra2 LVD (80 Mb/s) <li> 53C896: Ultra160 (160 Mb/s, two channels) </ul> The part numbers might have NCR, SYM or LSI prefixes. The 5 suffix indicates support for a BIOS ROM - which can be serial or flash, programmable in situ - this is mainly to help ignorant PCs boot from SCSI. It's not clear if this will be needed for AmigaOne - probably not if there's room for a bootstrap loader in the ROM that configures PCI, but if not we should be able to put our own code in without much trouble. Do not confuse these with the old 5380 chips used in old Macs (and Emplant). These were very limited in speed and required host interventions for every SCSI phase change. The 53C90 (in Mac 2s) could get by with about half as much driver code as it had hardware arbitration for common SCSI bus state changes, but it was still a 'dumb' chip reliant on interrupting the host whenever a decision needed to be made. Drivers for all the smart chips are very similar, and a lot shorter and simpler than the drivers for rival SCSI controllers, thanks to a (very) RISC 'SCSI scripts' processor which takes all the load of SCSI bus phase control off the main system, and the programmer of the driver :-) The SCSI scripts program and state machine works out whether we are handling commands or data, resolves contention and hard and soft errors, allowing drives to disconnect and reconnect so they don't clog the bus while they perform internal operations, etc... The result is a driver that looks simple but handles all complicated cases implicitly, and takes multi-threading in its stride. SCSI scripts are made of 64 or 96 bit RISC instructions read from the host memory by DMA or from internal memory on later chips in the series. We don't need to write a SCSI script program, though it may be useful - NCR's standard ones cope with all the SCSI phases and types of transfer, and most implementations just use them and wrap host code around it to trap completion interrupts and set it off again. The 53C7xx and 53C8xx parts have a relatively tiny host overhead - between one and five per cent of that for a second-generation 53C90 - because once you've told it what to do the controller goes ahead and does it, coping with disconnection and reconnection so other devices can share the bus and the host doesn't have to wait for seeks - a major advantage of SCSI over IDE - and scatter/ gather operations for blocks fragmented through memory, which will be significant in implementing virtual memory. Anyhow, arbitrarily-sized blocks of data are moved to or from host memory by PCI DMA and the only interrupt is at the end when the job - or a sequence of transfers - is done, or if an error occurs in the meantime. You don't have to use DMA or SCSI scripts, though it is most efficient - for test purposes you can treat the controller as an entirely dumb one and peek and poke a byte at a time, which may be useful for a minimal bootstrap or support for sub-standard peripherals. It can do more than just read and write the SCSI bus - as it has bidirectional DMA you can use it as a general-purpose block transfer device to take the load off the CPU when moving data around main memory or between motherboard RAM and video RAM, let's say. It can even do horizontal and vertical scrolling and window operations, though you'd probably want do this using the video card local CPU and bus in practice :-) The memory move instruction is stunningly simple, and a good example of SCSI scripts. It's 96 bits long. The first byte is 192 (top two bits set - these sift between four basic RISC instruction groups). The rest of the first (long) word is a 24 bit count of bytes to be moved. The next two words are the 32 bit source and destination addresses. The main limitation is that those must have the same byte alignment, as the chip does 32 bit transfers, and tries to collect them in line bursts if appropriate. We don't strictly need this, but if we were to make our driver offer this functionality to applications (with a hardware abstraction using the host processor or anything else appropriate if the SCSI copro is not present) we would be making better use of PCI and our choice of hardware than any other non-embedded system. Likewise our SCSI device should support the whole SCSI spec - not just transfers between SCSI devices and memory, but between hosts sharing a bus - no problem as long as they have different SCSI IDs - we should eschew cards that fix the ID at 7 as it's an avoidable limitation - and then they can all share CD ROMs and other peripherals - even writable drives with careful (software) arbitration. And yes, I *know* this works, even on the old Amiga - I've seen Linux and AmigaOS sharing drives on a SCSI chain this way, and there's a SCSI networking example on Aminet that uses SCSI direct commands to make a fast parallel heterogenous drive and computer cluster. There are other ways to do this - Firewire, Ethernet, even USB at a pinch - and I don't suggest that we should put effort into implementing it ourselves - but we should specify hardware and drivers that do not prevent it if we or third parties see value in the concept, later. Software issues The whole thing should be wrapped in whatever scheme we use for DMA device drivers, so we're not committed to the NCR family if something else comes along and we write fresh drivers for it. We have to support synchronous and async I/O, and SCSI-direct (which is the Classic Amiga scheme to allow any command to be sent directly to any device in a host-independent way). The existing API is fine, and hence any superset of it would be, except that the late addition of QuickIO - where a device call may take place in the caller's context, without contextr switching to another handler or device driver task, and does not return till complete - needs to be made a core, guaranteed part of the spec. QuickIO could have been very useful to address complaints about the OS getting in the way of dedicated high performance systems like multi-tracking, but wasn't useful in old Amiga products since not all handlers and device drivers implemented it and Commodore defined it as an option, not a requirement (so it was widely ignored). This was a good idea which we should follow through. SCSI-direct allows custom support for new standard extensions, non-standard or broken devices (like the NEC drives that interpret binary parameters as BCD! 8-) by passing arbitrary SCSI commands to a device, and marsalling the results, in a way that does not obstruct standard uses or sharing of the SCSI bus. SCSI-direct allows specialist applications to use some of the SCSI features that are not available on IDE or other types of drive. For instance a SCSI drive can be programmed to search itself (with fields to skip and check) and call any other device back when it has found certain data. This requires a command with no equivalent for other types of devices, which would have to read all the data over the bus and check it with the main CPU. We could add this function to our API and do it the hard way for non-SCSI devices and cleverly for SCSI ones, but there is no need to make this a standard interface - as long as SCSI direct is available, programs for dedicated database or streaming applications can access the functionality without making life more complicated for conventional applications. It would probably be worth adding this, especially if SCSI takes off on Amiga or other drives (e.g. over ATAPI or firewire) offer equivalent functions, but this should not be a priority. For the time being SCSI-direct meets the requirement for those that understand and need it. As it is a low-level path into code that already exists to implement more abstract I/O operations, the cost of making it available is tiny, and we can build on it ourselves, for instance to extend third-party drivers in an Amiga-general way. Another neat trick possible with SCSI-direct, as long as you know the topology of your system in a bit more detail than device-independence allows, is to program a drive to copy or mirror itself to another. This can be done without host intervention (other than reselection when it is done) as all SCSI devices - not just the host - can master the SCSI bus and transfers can be between any two devices, without blocking processes of other transfers, subject to well-defined and efficient priority and bus sharing protocols. Horray for SCSI! Horray for SCSI scripts processors! </td> </tr> </table> </body> </html>